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I.  INTRODUCTION  AND  SUttiARY 

Operations  researchers  and  systems  analysts  are  increasingly  con¬ 
cerned  with  information  system  design.  Operations  research  has  tradi¬ 
tionally  been  concerned  with  physical  production,  distribution,  and 
stoclcage  problems.  In  these  areas  operations  researchers  using  tech¬ 
niques  such  as  simulation,  Delphi  methods,  and  operational  gaming,  gen¬ 
erally  aim  at  finding  strategies  —  decisions  that  take  account  of  im¬ 
portant  variables  at  the  time  the  decision  is  made.  The  Operations  Re¬ 
search  approach  has  not  been  noticeably  successful  in  improving  the 
Information  Systems  Design  process  or  the  resulting  product. 

This  paper  develops  the  following  points: 

1.  Various  factors  cause  transition  to  new  information  systems. 

2.  The  traditional  systems  analysis  approach  is  a  "top-down"  de¬ 
sign  --  specifying  goals,  objectiver  ,  decision  variables, 
policies,  and  finally  informetion  ^/stern  specifications. 

3.  Organizations  typically  fellow  a  "I  rttom  up"  or  "inside  out" 
design  approach. 

4.  "Bottom  up"  design  occurs  because  of  Institutional  incentives 
and  because  of  the  complexity  of  modem  systems. 

5.  The  "bottom  up"  design  process  typically  yields  degraded  per¬ 
formance  . 

6.  We  must  consider  incremental  or  phased  development  that  pre¬ 
serves  design  options. 


.\ny  views  expressed  in  this  paper  are  those  of 
should  not  be  interpreted  as  reflecting  the  views  of 
tion  or  the  official  opinion  or  policy  of  any  of  its 
private  research  sponsors.  Papers  are  reprodviced  by 
tion  as  a  courtesy  to  members  of  its  staff. 
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11.  LARGE  INFORKATIOM  SYSTEMS 

An  information  system  is  an  evolving  organization  of  people,  compu¬ 
ters,  and  other  equipment  (associated  connunication  and  support  systems) 
and  their  integrated  operation  to  regulate  and  control  selected  environ¬ 
mental  events  to  achieve  systems  objectives. 

In  a  complex  organization,  an  information  system  performs  the  same 
function  as  the  nervous  system  in  the  human  body.  Thi‘$'  paper  deals 
with  information  systems  used  by  managers  and  planners  in  very  large  or¬ 
ganizations.  Such  systems  may  be  as  simple  as  item  stock  level  reports 
in  a  chain  of , warehouses  or  as  complex  as  systems  that  come  into  play 
when  an  expensive  spare  part  is  required  by  an  out-of-comnission  aircraft 
at  a  remote  airfield.  Stockage,  airlift,  and  procurement  information  as 
well  as  repair  computations  may  be  required  to  determine  the  point  of 
origin  for  resupply  of  the  required  part.  A  typical  logistics  informa¬ 
tion  system  consists  of  several  ccxnplexes  of  computers  tied  together 
with  owned  or  leased  coninunication  facilities.  Logistics  managers  may 
interact  with  the  information  system  in  making  daily  decisions,  and  may 
enter  their  decisions  back  into  the  information  system. 

Information  system  concepts  have  developed  more  slowly  than  hard¬ 
ware.  Most  attention  in  large  systems  has  been  directed  at  the  transi- 
cLon  between  second  and  third  generation  computer  equipment-.  Second 
generation  systems  are  characterized  by  serial  memory  (tape  units),  se¬ 
quential  batch  processing,  and  only  one  user  at  a  time  on  the  central 
processor.  Third  generation  systems  are  characterized  by  direct  access 
memory,  various  terminal  options,  multi-programming,  and  multi-user 
time  sharing.  _ 

The  complexity  of  an  information  system  depends  on  many  factors. 

A  few  are  listed  below. 

-  Nature  of  Use:  An  information  system  used  for  interactive  analy¬ 
sis  is  more  complex  than  one  simply  used  for  data  processing  and 
report  generation. 

-  Number  of  Installations:  Complexity  increases  as  the  number  of 
interconnected  installations  increases. 


-  Divers!^  of  Equipment:  Problems  of  standerdizacion  and  conver¬ 
sion  are  compounded  with  diverse  equipment. 

-  Number  of  Simultaneous  Users:  The  executive  routines  to  handle 
many  simultaneous  users  are  complex  and  costly. 

-  Size  of  Data  Base:  Data  management  systems  for  very  large  files 
and  very  large  records  are  still  being  developed. 

-  Frequency  of  Data  Changes:  The  efficiency  of  file  management 
systems  is  increasingly  important  as  the  frequency  of  data  up¬ 
dates  increases. 

-  Interaction  of  Transactions  (Cascading) :  Performance  of  systems 
in  which  one  event  triggers  several  ethers  is  less  predictable. 

-  Extent  of  Imbedded  Decisionmaking:  Complexity  increases  as  al¬ 
gorithms  for  decisions  are  imbedded  in  the  information  system 
and  triggered  automatically. 

III.  SYSTBi  DESIGN  OR  CONVERSION 

Several  factors  may  lead  to  initiation  of  system  change  -■■  either 
design  anew  or  conversion.  Workloads  increase  over  time.  Facilities 
begin  to  wear  out  and  require  increased  maintenance.  Fashions  in  com¬ 
puting  change.  Increased  operating  flexibility  is  desired.  Speed  of 
hardware  (not  software)  improves  and  arguments  concerning  decreased  dol¬ 
lar  costs  of  each  computing  operation  are  difficult  to  ignore. 

Transition  may  involve  shifting  transactions  from  one  system  to 
another,  perhaps  only  through  software  or  hardware  changes,  but  perhaps 
also  by  policy  changes,  and  perhaps  by  changing  from  batch  to  on-line 
processing . 

Even  "simple"  hardware  or  software  conversion  can  involve  several 
considerations.  Standardization  can  be  a  significant  problem  in  multi¬ 
facility  system.  In  converting  hardware  in  such  systems  we  find  that 
physical  separation  leads  to  operating  differences.  This  is  compounded 
if  generations  and  manufacturers  of  equipment  are  different.  File  con¬ 
version  and  program  conversion  are  more  difficult  in  a  multi- facility 
system.  Staff  training  in  a  new  system  is  always  required,  and  planning 
for  additional  physical  space  and  power  if.  too  often  overlooked. 
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IV.  TOP-DOWN  DESKM 

Systems  analysts  tend  to  reconsnend  top-down  design.  Top-down  de¬ 
sign  proceeds  from  the  ideas  of  constrained  optimization.  It  attempts 
to  look  at  an  overall  organization,  its  policies,  and  their  interactions. 

Changes  in  decision  aud  operating  procedures  appear  to  be  the  source 
of  the  major  dollar  and  effectiveness  gains  in  organizations.  New  tech¬ 
nology  may  be  required  to  implement  desired  decision  and  operating  pro¬ 
cedures,  and  introduction  of  new  technology  may  be  an  essential  step. 
However,  resources  available  for  system  development  are  generally  lim¬ 
ited,  often  severely.  When  an  initial  decision  is  to  cake  a  very  large 
step  in  introducing  new  technology,  policy  improvement  will  inevitably 
suffer.  The  problems  associated  with  simply  making  new  technology  run 
absorb  most  of  the  staff.  Top-down  planning  stresses  policy  and  upgrades 
technology  only  as  necessary.  Once  a  policy  base  exists,  the  full  range 
of  new  technology  can  be  introduced.  Processing  requirements  generate 
costs.  The  comparison  of  policy  benefits  with  processing  costs  dictates 
the  choice  of  both  policy  and  information  processing  schemes.  Process¬ 
ing  parameters  and  available  technology  then  lead  to  hardware  selection. 

Top-down  design  typically  relies  on  analytic  decision  procedures. 
Such  planning  emphasizes  decision  procedures  to  avoid  trouble  rather 
than  ad  hoc  procedures  to  get  out  of  trouble.  Analytic  models,  sinula- 
tion,  and  cost-effectiveness  analyses  are  used  to  evaluate  the  worth  of 
policy  improvements. 

Expending  resources  on  modeling  and  experimentation  requires  a 
tradeoff  between  time  and  uncertainty.  The  more  effort  put  into  experi¬ 
mentation  and  analysis,  the  greater  the  reduction  in  uncertainty  about 
the  performance  of  the  ultimate  system  and  reduction  in  the  consequent 
risk  that  it  will  be  inadequate.  The  less  effort  put  into  experimenta¬ 
tion  and  analysis,  the  faster  a  system  gets  designed  and  implemented; 
but  with  more  attendant  uncertainty  and  risk  about  ultimate  pf.rformance . 
Obviously,  when  time  is  available,  simulation  can  be  of  great  benefit. 

Top-down  design  can  be  likened  to  a  complex  decision  tree  with  suc¬ 
cessive  branches  in  policy,  information  processing  concepts,  and  hard¬ 
ware  configuration. 


PROCESSING 

fOLICIES  CONCEPTS  HARDWARE 


Policies  might  Include  decision  procedures  for  Stock  Distribution, 
industrial  Repair  Scheduling,  Procurement  Policy,  or  EOQ  Purchases. 
Processing  concepts  consider  the  degree  of  man' machine  Interaction,  mix 
of  batch  and  on-line  processing,  types  of  data  base,  file  management 
systems,  and  the  degree  of  system  autonomy  or  manual  override.  Hard¬ 
ware  considerations  Include  the  tremendous  range  of  processors,  termi¬ 
nals,  and  f to rage  units  available. 

Very  little  Is  known  about  where  to  stop  analyzing  and  experiment¬ 
ing  and  start  Implementing.  While  sound  analysis  and  experimentation 
Ic  necessary,  we  can  only  base  ou..  decisions  on  subjective  estimates  of 
the  utility  of  additional  research. 

Rand's  general  approach  has  been  to: 

(1)  Develop  formal  simulation  models  of  the  entire  system  under 
consideration  to  ise  In  evaluating  alternative  management  policies; 

(2)  Develop  detailed  simulation  or  analytical  models  of  the  pro¬ 
posed  software  (data  management  and  multlprograiunlng  systems  for  ex¬ 
ample)  and  experiment  with  these.  For  example  see  how  systems  behave 
against  different  Input  distributions  and  stud^-  the  tradeoffs  between 
data  redundancy  and  Information  retrieval  times. 


(3)  Develop  botli  gross  and  detailed  simulation  models  for  use  in 
cost-effectiveness  and  decision-rule  studies.  These  models  are  elabora¬ 
tions  of  the  system  models  first  developed.  They  incorporate  more  of 
the  functional  details  developed  during  the  system  requirements  deter¬ 
mination  and  system  integration  phases  and  the  computer  processing  de¬ 
tails  developed  during  the  software  requirements  development  phase. 

Thus,  they  are  able  to  attaci  costs  to  specific  procedures  and  process¬ 
ing  methods  and  evaluate  the  benefits  achieved  through  their  use. 

(4)  Survey  similar  industrial  and  military  systems  and  collect 
statistics  on  software  performance.  Determine  what  overhead  factors  are 
being  incurred  and  how  existing  multiprog ramning  monitors  work. 

(5)  Finally  select  software  structure. 

In  summary,  top-down  design  of  information  systems  is  characterized 
by  a  strong  degree  of  sequential  decisionmaking  based  on  improved  infor¬ 
mation.  It  is  illustrated  in  Figure  1  and  summarized  below. 

-  Establish  organizational  missions  and  goals. 

-  Develop  evaluations  of  policies  through  analysis  and  sinula- 
tion. 

-  Explore  alternative  information  processing  concepts: 

-  Degree  of  on-line  vs.  batch  processing 

-  Degree  of  man-machine  interaction 
Frequency  of  update 

-  Degree  of  data  base  redundancy 

-  Test  a  variety  of  information  system  options  for  feasibility 

-  Compare  costs,  performances  of  information  system  options 

-  Develop  and  follow  an  implementation  plan: 

Delivery,  checkout  tests 

-  Plans  for  tuning  the  new  system  to  attain  high  per¬ 
formance 

-  Support,  training  plans 
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V»  BOTTOK-UP  DESIGN 

The  opposite  of  the  top-doira  approach  is  "bottom-up"  or  "inside- 
out"  analysis.  It  starts  with  arbitrary  decisions  at  some  detailed 
level  of  design,  or  decisions  about  specific  management  policies  of  the 
system.  It  may  contain  a  detailed  model  of  one  part  of  the  system,  and 
by  a  process  of  addition,  build  to  an  overall  system  picture.  As  an 
example,  equipment  modernization  in  most  corporations  has  led  from  407 
punch  card  equipment  to  704  computers  to  7090  computers  to  360/65  com¬ 
puters  with  no  change  in  processing  rules  or  frequency  ot  extent  of  in¬ 
teraction  between  transactions. 

Bottom-up  design  forces  low-level  decisions  in  restricted  contexts. 
It  is  further  characterized  by  arbitrary  selection  of  hardware.  Organi¬ 
zation  policies  are  set  before  any  overall  planning  or  cost/effective¬ 
ness  studies  are  undertaken,  and  important  policy  decisions  are  made 
without  evaluation  of  their  consequences.  Bottom-up  decisions  fre¬ 
quently  reflect  a  desire  to  utilize  new  and  perhaps  attractive  computer 
hardware  rather  than  a  commitment  to  improvement  in  the  organization's 
overall  performance.  Policy  innovations  receive  marginal  attention,  and 
enthisiasm  is  directed  at  modernizing  the  processing  equipment.  Given 
this  initial  conceptual  set,  system  design  effort  tends  toward  feasibil¬ 
ity  rather  than  system  performance  or  cost. 

Bottom-up  design  is  frequently  also  characterized  by  strong  paral¬ 
lel  or  concurrent  structure.  Simultaneous  choice  of  management  policy 
and  hardware  configuration  occurs,  and  software  must  bridge  a  possibly 
unbridgeable  gap. 

Most  design  efforts  observed  in  practice  appear  to  initially  empha¬ 
size  e.stimat<!  system  hardware  requirements,  and  later  emphasis  is  on 
modification  to  achieve  feasibility  rather  than  on  design  exploration 
and  experimentation  to  improve  organizational  perfornance. 

If  we  characterize  the  effects  of  bottom  up  design  on  the  policy, 
infonnation  concepts,  and  hardware  tree,  the  tree  gets  bare  rapidly. 


POLICY 


INFORA^TION 

PROCESSING 

CONCEPTS 


HARDWARE 


VI.  DAttGER  OF  BOTTOM-UP  DESIGN 

Bottom-up  design  Leads  to  system  deficiencies.  Arbitrary  schedules 
policies,  development  paths,  and  system  boundaries  lead  to  independent 
inclusion  of  different  policies  at  different  time  points  without  know¬ 
ledge  of  their  interactions  and  implications.  This  can  stunt  the  crea¬ 
tivity  of  designers  since  there  is  no  overview  from  which  to  predict  in¬ 
teractions  or  effects.  Thus  there' is  no  formal  way  to  introduce  new 
policies,  and  no  valid  means  of  predicting  or  evaluating  policy  and  sys¬ 
tem  performance. 

The  rapid  and  frequently  simultaneous  pruning  of  the  decision  tree 
in  policy  and  hardware  configurations  leaves  software  to  fill  the  gap. 
This  may  lead  to: 

(1)  Infeasibility :  A  management  evaluation  system  may  provide  no 
data.  Or  there  may  be  no  interfaces  between  transactions. 

Or  a  communication  system  may  break  down  under  heavy  volume. 

(2)  Performance  degradation  and  system  rigidity;  After  implemen¬ 
tation  the  entire  information  system  cannot  be  altered.  There 
fore  fewer  applications  may  be  run,  or  less  frequent  updating 
than  originally  planned  may  be  permitted. 
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es)  Schedule  slippage  may  occur  in  constructing  software  or  hard¬ 
ware  specifications,  or  in  equipment  deliveries,  or  in  devel¬ 
opment  of  feasible  policy  applications. 

(4)  Increased  equipment  cost  may  be  incurred  when  extra  equipment 
is  procured  to  permit  minimally  acceptable  system  performance. 

VII.  WHY  DOES  BOTTOM-llP  RATHER  THAN  TOP-DOWN  DESIGN  OCCUR? 

Bottom-up  design  is  simpler.  Top-down  design  requires  determina¬ 
tion  of  organizational  and  policy  goals.  These  are  difficult  to  obtain. 
Policy  effects  and  interactions  are  difficult  to  model.  Moreover, 
bottom-up  design  rapidly  eliminates  uncertainty  and  yields  --  on  paper  - 
a  straightforward  implementation  plan  which  is  easy  to  monitor.  The 
arbitrariness  is  unnoticed  until  too  late. 

Management  is  generally  not  involved  in  system  design.  Technicians 
are  typically  in  actual  charge,  and  it  cannot  be  assumed  that  the  or¬ 
ganization's  data  processing  professionals  understand  corporate  managers 
responsibilities.  It  is  easier  for  the  design  organization  to  prepare 
equipment  specifications  than  to  assess  management  needs  of  diverse  or¬ 
gan  izat ions . 

Procurement  mechanisms  in  large  organizations  are  tedious.  System 
specifications  are  sometimes  desired  rapidly.  "Buying  in"  ahead  of 
other  capital  expenditures  in  the  organization  may  be  desirable.  Speed 
drives  the  designer  to  concurrency  in  policy  and  hardware  selection 
which  requires  development  of  general  purpose  software  independent  of 
any  machines.  Such  software  may  itself  be  di.fficult  to  develop  and 
probably  can  contain  only  a  small  subset  of  standard  languages. 

Bottom-up  design  flourishes  because  costs  and  performance  evalua¬ 
tion  of  system  specifications  is  difficult.  The  performance  of  a  com¬ 
puter  is  not  determined  by  either  the  hardware  or  the  software  alone. 

The  performance  of  an  installation  (hardware,  software,  and  procedures) 
depends  strongly  and  markedly  on  the  hardware  configuration.  Computing 
standards  do  not  yet  exist  for  many  areas.  Metrics  have  not  been  iden¬ 
tified  or  established.  Costing,  especially  as  it  relates  to  procure¬ 
ment,  does  not  reflect  true  consumption  of  resources.  Because  of  all 


these  factors  the  technical  evaluation  process  is  sometines  weak,  and 
lags  behind  the  complexity  of  systems.  Thus,  top-doim  design  is  not 
usually  used.  It  is  expensive  In  dollars,  time  consuming,  and  may  lead 
to  loss  of  momentum.  Short  time  schedules  for  system  implementation 
frequently  preclude  appropriate  planning  efforts. 

VIII.  ACmEVDiG  FEASIBILITY  IN  THE  BOTTOM  HP  WORID 

In  the  presence  of  such  realities  how  may  we  assure  feasibility  for 
large  systems? 

(1)  "Buy  it  and  try  it."  A  cannon  approach,  but  not  good  for  very 
large  systems  since  the  expense  is  infeasible. 

(2)  Tune  the  existing  installation  and  add  equipment  as  necessary. 
This  is  especially  attractive  since  cost-benefit  arguments  for 
new  systems  are  generally  not  borne  out. 

(3)  In  designing  a  ne«  system  use  experts  —  they  are  much  less 
expensive  than  in-house  personnel.  Also  modify  organizational 
procedures  to  fit  canned  routines  and  systems  (accounting, 
payroll) . 

(4)  Use  a  phased,  staged,  prototype  approach  to  implementation  of 
large  systems. 

(5)  Preserve  flexibility  and  back  up  by  keeping  the  old  system  as 
long  as  you  can,  and  buying  program-compatible  equipment. 

(6)  Rent  equipment  with  an  option  to  return. 

(7)  If  you  must  buy  equipment,  buy  modular  equipment  with  excess 
core  capacity. 

(8)  Weigh  procurements  in  favor  of  vendors  with  families  of  equip¬ 
ment. 

(9)  Following  installation,  conduct  performance  audits,  tune  con¬ 
figurations  for  additional  performance,  and  return  unneeded 
equipment. 
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IX.  SDMmg 

Top-down  design  will  not  in  general  be  accomplished  unless  a  rela¬ 
tively  long  time  for  development  exists,  and  an  excellent  consultant 
group  is  on  hand.  In  cases  where  the  developing  organization  has  had 
infomation  system  experience,  the  design  team  will  probably  use  an  in- 
cremental  approach  rather  than  a  top-down  design  approach. 

Since  modern  information  systems  are  complex  beyond  intuition,  con¬ 
sultants  must  realize  that  simple  historical  examples  and  homilies  pre¬ 
sented  to  the  acquiring  organization  will  not  work.  Criticism  will  be 
ignored.  Specific  implementable  suggestions  and  specific  citations  and 
demonstrations  of  infeasibility  are  required. 

Consultants  must  emphasize  design  for  flexibility  and  change,  as 
well  as  continuing  to  advocate  modeling  and  analysis.  Rand's  empirical 
studies  and  observations  of  past  development  projects  lead  us  to  believe 
that  a  highly  phased  development  strategy  is  preferred.  Rather  than  al¬ 
locate  available  resources  across  many  subsystems,  focusing  resources  on 
one  or  several  critical  subsystems  has  several  advantages.  First,  sub¬ 
systems  are  available  in  the  shortest  possible  time.  This  strategy  per¬ 
mits  a  staff  of  modest  size  and  thus  a  higher  quality  level  can  be  main¬ 
tained.  Subsystems  that  appear  later  in  the  effort  can  profit  from 
learning,  further  policy  development,  field  tests,  and  simulation  exer¬ 
cises.  Management  and  control  of  phased  development  are  easier  since 
managers  do  not  have  to  make  decisions  and  follow  progress  in  as  many 
concurrent  efforts.  Phasing  also  allows  management  to  recognize  that 
areas  differ  in  terms  of  (a)  payoff,  (b)  amount  of  prior  work,  and 
(c)  ease  of  development.  Phasing  does  present  some  difficulties.  Some 
parts  of  the  system  must  be  redesigned  and  reprogrammed  but  evidence 
suggests  that  the  total  cost  of  the  phased  approach  is  lower.  The  real 
danger  of  the  phased  approach  is  cancellation  or  loss  of  momentum  prior 
to  completion.  Resolution  of  this  problem  depends  on  the  organization's 
procurement  policy  and  on  the  role  taken  by  top  management. 

Backup  and  flexibility  must  be  pressed  as  key  factors.  Development 
is  difficult  and  uncertain.  Since  management  systems  always  take  longer, 
cost  more,  and  work  less  well  than  planned,  backup  is  crucial.  Existing 
systems  should  be  maintained  so  that  chey  can  operate  longer  if  necessary. 
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Buying  new  equipaent  that  ia  prograa  cowpatible  with  existing  equipnent 
provides  extensive  backup  but  nay  be  an  unavailable  or  undesirable  op¬ 
tion  for  other  reasons.  Adequate  backup  gives  the  developamut  nanager 
i^tortant  flexibility.  If  he  encounters  a  need  for  Bodification  or  ad¬ 
ditional  testing  that  will  deliqf  his  pingraa,  he  can  Mke  his  decision 
on  the  costs  and  gains  involved  rather  than  being  forced  to  neet  the 
schedule.  Hodularity  in  design  can  be  achieved  by  selecting  equipk..3nt 
to  allow  rental  or  purchase  add-ons,  to  change  terminal  equipaent,  and 
number  of  peripherals,  and  to  change  data  transmission  volumes.  Rental 
flexibility  is  especially  important  since  they  permit  return  of  parts  of 
the  system  on  short  notice. 

Prototyping  portions  of  the  installation  should  be  encouraged. 
"System"  utilization  is  a  misleading  phrase  if  it  is  not  known  irhich 
part  is  critical  —  saemozy,  communications,  or  the  CIV.  One  can  in¬ 
stall,  and  measure  the  utilization  rate,  with  actual  loads  and  then  add 
equipment  where  necessary.  Horeover  "system"  performance  in  the  ab¬ 
stract  generally  ignores  software  and  staff  skills  which  are  observable 
in  the  installation. 

Management  pla!ning  is  required  to  produce  the  system  plan  and  to 
build  the  system.  Organization  is  not  a  final  answer  to  any  problem, 
but  it  is  important  that  (1)  a  strong  management  role  be  present  through¬ 
out  development  to  maintain  the  policymaking  or  management  function, 

(2)  the  project  be  reviewed  at  top  management  level  to  achieve  a  cross¬ 
function  view,  and  (3)  the  project  group  include  both  functional  and 
computer  personnel  to  allow  the  close  interaction  needed  in  modem 
systems . 

Modern  systems  analysis  is  an  effort  to  apply  structured  rational¬ 
ity  to  problems  of  choice.  To  be  of  use  in  Information  Systczr.  J,.sign 
in  large  organizations  the  analyst  must  be  aware  that  his  techniques  of 
analysis  require  time  and  data.  Neither  may  be  available.  Tlie  analyst 
must  also  understand  that  institutional  factors  cause  real  design  to 
proceed  from  simultaneous  policy  and  hardware  selection  through  software 
to  the  final  system.  The  analyst  must  therefore  supply  advice  on  policy 
phasing,  equipment  phasing,  flexibility,  and  backup.  Our  emphasis  must 
be  on  creativity-preserving  options,  and  we  nwst  plan  tor  the  freedom  of 
the  next  planner  of  the  system. 


